feat: 알림 조회·읽음 처리 API (GET/POST notifications) - #123

왜 필요한가요?

Refs #15

PR #115, #119 위에 이어서, Notification 도메인 전체(테이블, 조회 API,
읽음 처리 API)를 추가합니다. 알림을 실제로 생성하는 로직(이벤트 기반)은
후속 PR로 분리했습니다.

완료된 범위

• V37: notification 테이블
• V38: notification RLS 정책
• Notification 도메인 (markAsRead()가 멱등하게 설계됨)
• NotificationRepository (cursor 기반 페이지네이션)
• GET /api/v1/notifications (unreadOnly, cursor, size 파라미터)
• POST /api/v1/notifications/{notificationId}/read
• recommendations의 review/after_approval을 dueDate 우선 정렬 (feat: today 대시보드 Agent 추천 요약 #119 )

결정 사항

• markAsRead()는 이미 읽은 상태면 자기 자신을 그대로 반환하도록 만들어,
  불필요한 DB 쓰기 없이 멱등성을 보장합니다.
• 아직 알림을 생성하는 로직이 없어-> 이벤트 생성을 의미, 통합 테스트는 DB에 직접 INSERT해
  테스트 데이터를 준비했습니다. 실제 생성 로직 검증은 후속 PR에서 다룹니다.

어떻게 검증했나요?

• ./gradlew clean test - 전체통과
• listReturnsItemsAndUnreadCount - 알림 2건(읽음 1, 안읽음 1) 준비 후
  목록 조회 시 items 2건과 unread_count 1이 정확히 나오는지 확인
• unreadOnlyFiltersReadNotifications - unreadOnly=true로 조회하면
  읽은 알림이 제외되고 안읽은 것만 나오는지 확인
• otherCompanyNotificationsAreNotVisible - 다른 사업장의 알림이
  내 목록 조회에 전혀 안 나타나는지 확인 (tenant 격리)
• readMarksNotificationAsReadAndIsIdempotent - 같은 알림에 읽음 처리를
  두 번 연속 호출해도 둘 다 204가 나오고, 목록에서 실제로 read=true로
  반영되는지 확인 (멱등성)
• readOnOtherCompanyNotificationReturnsNotFound - 다른 사업장의
  알림을 읽음 처리하려고 하면 404가 나오는지 확인 (존재 여부도 노출 안 함)
• NotificationTest (도메인 단위 테스트) - buildRoute()가 TASK/WORKER/
  DOCUMENT 각각 정확한 경로를 생성하는지, route가 항상 target_id를
  포함하는지, markAsRead()가 멱등한지 확인
• notificationsAreIsolatedBetweenUsersInSameCompany - 같은 회사
  내 다른 사용자(HR_A2)에게는 HR_A의 알림이 전혀 보이지 않는지 확인
• hasNextIsFalseWhenExactlySizeItemsRemain — 정확히 요청한 개수(3개)
  만큼만 남아있을 때, has_next가 false로 정확히 나오는지 확인
  (+1 전략 이전에는 이 경계에서 잘못 true가 나올 수 있었음)
• hasNextIsTrueWhenMoreItemsRemain - 요청한 개수보다 많이 남아있을
  때, has_next가 true로 정확히 나오고 items는 요청한 개수만큼만
  잘리는지 확인

리뷰 반영

• user_id 추가: notification 테이블에 user_id 컬럼을 추가하여,
  같은 회사 내 다른 사용자에게는 읽음 처리가 전파되지 않도록 수정했습니다.
• route 자동 생성: target_id와 route를 각각 입력받던 방식에서,
  target_type + target_id로 서버가 route를 직접 생성하도록
  변경했습니다(Notification.buildRoute()). target_id와 route가
  서로 다른 값을 가리키는 불일치가 구조적으로 불가능해집니다.

추가 개선

• cursor 페이지네이션에 +1 전략을 적용해, has_next 필드가 경계값에서도
  정확하도록 수정했습니다.